BBS Toolkit/BBS Toolkit.iso/doors_1/lvcat35m.zip/UPGRADE.DOC

Text File | 1992-04-07 | 20KB | 456 lines

                      LiveCat Version 3.5/TDM+

                     LIMITED TEST DRIVE VERSION

                           Upgrade Notes
                                and
                       Installation Addendum


                      Release date: 03-22-1992


  Welcome to the 3.5 version of the Live Systems Door Monitor
series!

  Version 3.5 is a maintenance release that fixes a few known  bugs,
adds a few new features that  have been asked for over the  last few
months,  AND  reworks  quite  a  few  internals  in  preparation for
Version 4.0, to be released in 3rd quarter 1992.

  This  document  is  an  addendum  to  the regular documentation for
versions 3.0, 3.1 and 3.13.   Since we are completely rewriting  the
documentation for version 4.0, we chose to not produce a full  update
to the 3.5 documentation  at this time.   We felt the time  would be
better spent working on Version 4.0.

  If you  are installing  the Door  Monitor for  the FIRST time then
you will follow the  installation instructions as documented  in the
regular  documentation,  while  referring  to  this document for any
differences.   In terms  of first  time installation  there are VERY
few differences.

  If  you  are  upgrading  your  installation  to  3.5  from any 3.x
then all you need  to do is read  this document for the  differences
in operation and for  those few items that  will need to be  changed
in your setup.

  For the most part,  this 3.5 upgrade is  a 'plug & play'  upgrade,
but there  ARE a  FEW changes  that you  might want  to make to take
advantage of the new features incorporated in V 3.5.


[[ Version 3.5 Change Log ]]

 Below is a brief listing of the changes, enhancements and additions
 you will find in V 3.5.

 1.)  ZKEY  menu  startup.   For  some  time  you have asked for the
     ability to  have the  monitor start  up running  the ZKEY menu,
     the menu  that a  user would  NORMALLY see  only by pressing 'Z'
     while inside the  monitor.  This  feature makes it  possible to
     bypass the BBS systems  door facility completely and  integrate
     the monitor  seamlessly into  the BBS.   The user  hardly  even
     knows that an outside program was run.  More later.

 2.)  New  internal  video  handlers  and  enhanced Ansi capability.
     Local screen displays are several times faster than before  and
     ansi  compatibility  of  the  internal  ansi  driver  is   much
     improved.

 3.)  In  the  3.x  release  the  TIME LOCK feature did not function
     properly.   The  ability  to  close  the  entire  doors  system
     between certain  hours had  been broken  and not  caught by the
     beta  team.   In  V   3.5  the  TIME  LOCK  feature   functions
     correctly.

 4.) Much improved handling of the USERS on-line time.  Version  3.5
     now  PROPERLY  handles  temporary  time  reductions  because of
     pending and  upcoming events  and will  not permanently reduce
     the users total doors time  because of this.  This  feature now
     also allows proper timing control on those systems that  permit
     split logons in a single day.  The monitor now calculates  time
     properly for those situations.

 5.) Improved DOOR.SYS compatibility.   In versions prior to 3.5  we
     only produced  the original  V1 DOOR.SYS,  not the  EXTENDED V2
     format as used by Wildcat! 3.0 and  GAP 5.x and 6.x.  In V  3.5
     we support BOTH  formats of DOOR.SYS.   Door type 'D'  (Generic
     Door.sys) writes the  standard V1 door.sys  and door types  'G'
     and 'O'  now produce  the EXTENDED  DOOR.SYS _FULLY_ compatible
     with Wildcat! 3.0 and GAP 5 & 6.

 6.) Added  LIMITED  support  for  WWIV  doors.  We now produce the
     CHAIN.TXT file required by WWIV doors.  More on this later.

 7.) Added  a PERMANENT  DOORS USERS  file.   This was  required for
     proper control of the users time and to clear the way for  some
     new features that will be added in V 4.0. More on this later.

 8.) Multi-Node users have long requested  a way to limit a door  to
     running  only   on  certain   nodes.    This  has    particular
     application for DesqView and  other multitasking systems.   You
     can now specify the highest COM PORT # that the door should  be
     allowed to run on.  More on this.

 9.) Multi-Node users  have asked for  a way in  an event to  UNLOCK
     any  doors  that  might  be  accidentally  left  in  a 'locked'
     condition.  A new  program called LOCKFIX.EXE is  included with
     V 3.5 and can be run in an event to unlock all locked doors.



10.) Version 3.5 is NOW available and FULLY supports the Ultra  BBS,
     it is known as LivePro/U.

11.) Increased use of Memory swapping techniques to speed  execution
     times.

12.) The bye  command in previous  versions (if used)  would log the
     bye as  a carrier  drop to  the BBS  caller logs.   For GAP and
     Wildcat!  3.x  systems  this  is  now  logged  as a normal user
     logout if you enable the BYE feature in the monitor.


  This documents MOST of  the changes present in  V 3.5.  There  are
others, mainly internal that you won't notice but provide  increased
reliability in a variety of circumstances.



[[ UPGRADING A 3.X VERSION OF THE MONITOR TO 3.5 ]]

  If you are already running a 3.x version of LiveCat then your
upgrade is VERY simple.  Follow these steps:

  1.) ERASE the following files before starting the upgrade.

      LIVECAT.EXE
      LSEDIT.EXE
      LSFIP.EXE
      LSPACK.EXE
      LSCONFIG.EXE

  2.) Go to the \WC30\WCWORK\NODE1 directory and ERASE MONITOR.CFG

  3.) If running MULTI-NODE go to each of your OTHER NODEx
      directories and ERASE MONITOR.CFG from those directories as
      well.

  4.) Copy the NEW .EXE files from this package to the directory in
      which you had the OLD versions of the .EXE files installed.

  5.) Go to the LIVECAT directory and ERASE LCUSER.DAT

  6.) Go to the \WC30\WCWORK\NODE1 directory and run LSCONFIG.EXE
      to create a new MONITOR.CFG for LiveCat 3.5.

  7.) If running MULTI-NODE go to each of your OTHER NODEx
      directories and run LSCONFIG.EXE in those directories as well
      to create a new MONITOR.CFG file the node.

  8.) Do NOT erase your LC.SYS file from any of the NODE
      directories.  This is your key file and LiveCat will NOT run
      without it.  The current LC.SYS is fully compatible with V
      3.5, you do NOT need a new key file.

 Thats it for the upgrade!  You can now reboot and things will run
as they did before.


[[ INSTALLING A FRESH 3.5 SYSTEM ]]

 If you are  installing LiveCat for  the first time  then follow the
installation instructions  in the  main documentation  file.   There
are no  differences to  document in  installation between  V 3.5 and
3.0 or 3.1.

  If  you  are  running  an  earlier  version  of LiveCat, V 2.0 for
instance, you  cannot upgrade  directly to  V 3.5.   You MUST  start
over, painful as it might be there is no alternative.



 [[ USING NEW FEATURES IN V 3.5 ]]


 This section documents the changes and new features of Version 3.5
in detail, read it carefully!

  * TIME LOCKING *

   All previous  versions of  LiveCat incorporated  a feature called
  VTL, or Vault  Time Lock.   The features allows  you to COMPLETELY
  LOCK down the doors system between certain hours of the day.

  In  Version  3.1  this  feature  was  broken  and did not function
  properly.  It has been fixed  in Version 3.5 and now functions  AS
  DOCUMENTED in the manual.  No changes to it's operation were  made
  other than to fix it.


  * ZKEY MENU STARTUP *

    This feature  was added  by popular  request.   Some BBS systems
  such as  Wildcat 3.x  and GAP  5 and  6 allow  the sysop to define
  custom menu  entries.   In Wildcat!  these are  called 'DOS HOOKS'
  and in  GAP they  are called  'Sysop Definable  Menu Items'.  This
  feature may be present in other supported BBS systems as well.

    What this  is for  is to  allow you  to use  one of  these sysop
  definable entries in your main menu to bypass the doors module  of
  the BBS and drop right into our  monitor.   To use this, define  a
  DOS HOOK  or SYSOP  DEFINABLE option  to whatever  key stroke,  or
  series of keystrokes you  want.  For WC  3.0 people you will  then
  create a MAIN1.BAT or a  MAIN2.BAT that contains the ZKEY  startup
  for the monitor.   GAP users would have  a batch file that  is the
  same NAME as the COMMAND that  shows in your main menu. Other  BBS
  owners will  use whatever  method is  available, if  any to create
  sysop definable menu entries.

  In this batch file you will simply put: LIVECAT MONITOR.CFG ZKEY

    You  would  of  course  substitute  LIVECAT  in  the  above with
  SUPERDOR, LIVEPRO,  WILDFIRE or  whatever is  appropriate for your
  system.  The  word  ZKEY  replaces  the  default  menu  that would
  normally go on this line.

    THIS FEATURE IS AN  OPTION! You DON'T need  to use it this  way.
  You can  still continue  to run  with the  monitor dropping into a
  default menu from  the BBS's doors  subsystem just like  it always
  did.  Unless you specifically want to use this feature you do  NOT
  need to change any of your LIVEx.BAT files or DOOR_X entries.

    It should be  noted that this  feature CAN be  used even if  you
  don't have definable menu entries.  This would serve to allow  ONE
  batch file ONLY to  enter the Monitor system.   If you define  ONE
  batch file  or DOOR_X  entry to  be a  ZKEY entry  point then  you
  might as  well do  away with  ALL the  rest of  the .BAT  files or
  DOOR_X entries since  the user finds  themselves in the  ZKEY menu
  instead of  a default  DOOR menu.   It should  simplify things for
  both you AND your users.


   * NEW INTERNAL USER TIME HANDLERS *

    This release drastically  alters the manner  in which the  users
  time remaining for doors is  maintained.  This is the  single most
  important and detailed change being  made in V 3.5. The  object of
  this change is  to cure the  situation where users  entering doors
  during  the  time  when  they  would  get a temporary reduction of
  their time because of  a pending event or  an imminent log off  in
  and a split log on situation.

    I had not intended at this  time to do away with the  LCUSER.DAT
  daily users file  and replace it  with a PERMANENT  Isam user file
  until version 4.0, but as I got into this I decided that since  so
  much work had to be done  there anyway that I'd just go  ahead and
  do it now.

    This version will CREATE a new Isam User file named  LCXUSER.DAT
  and  LCXUSER.IDX  when  it  is  run  the  first time.  The file is
  permanent and will maintain user records forever in the manner  we
  need.  This should be totally transparent to you when the file  is
  created and the old one becomes obsolete.

    This change  should make  timing problems  with split-logons and
  pending event time reductions transparent and error free.

  * IMPROVED DOOR.SYS COMPATIBILITY *

    There are now TWO different  versions of DOOR.SYS being used.  I
  refer to  them as  DOOR.SYS I  and DOOR.SYS  II, DOOR.SYS II being
  commonly referred to as 'Extended DOOR.SYS'

    Previous versions of the monitor produced ONLY a DOOR.SYS I  for
  doors requiring DOOR.SYS.   This caused problems  with SOME  doors
  written specifically  for Wildcat!  3.x in  which the  door author
  tried to read in the FULL  EXTENDED DOOR.SYS II which we were  not
  creating.  This  would commonly result  in INPUT PAST  END OF FILE
  ERRORS when attempting to run the door.

    To accommodate this  the new LSFIP  now supports BOTH  formats of
  DOOR.SYS, if you mark a door as 'D' type it will create the  older
  DOOR.SYS I format still used by  many doors, if you mark the  door
  as  a  'G'  or  'O'  type  door  it  will  now create the EXTENDED
  DOOR.SYS II format as used by GAP 5.x+ and Wildcat!  3.0+.

    This SHOULD  clear up  any problems  you might  have been having
  doors written specifically for the Wildcat! 3.0 interface.


  * LIMITING DOOR RUNS TO CERTAIN NODES (multi-user only)

    For a long time some of you that run multi-nodes under  DesqView
  or some other  multi-taskers have been  asking for a  way to limit
  which nodes a door can be run  on.  In this version LSEDIT adds  a
  new field to the door attributes window called:

  Highest Comport to Allow (1-8):

    What ever number you place here is the HIGHEST comport that  the



  monitor will  allow the  door to  be run  on.   For instance,  you
  might  have  4  nodes  running  under  DV, on COM1, COM2, COM3 and
  COM4.  You install  a new door that  only supports COM1 and  COM2.
  In this field in the attributes put the number 2, indicating  that
  COM2 is the highest comport  number the door should be  allowed to
  execute on.  A user  on node 3 or node  4, COM3 or COM4 trying  to
  execute the door will now  get an error message telling  them that
  this can not be run on  this node.  This should solve  the problem
  for you.


 * INCREASED USE OF MEMORY SWAPPING *

    We  had  been  having  random  reports  in  V  3.1 and 3.13 that
  sometimes under  certain circumstances  LSFIP would  create a ZERO
  length PCBOARD.SYS  and PCBOARD.DAT  file.   I've finally  I THINK
  traced this to a memory problem.  In ALL previous versions of  the
  monitor  LSFIP  was  SHELLED  from  the  monitor, meaning that the
  monitor  remained  in  memory  and  shelled  command.com and lsfip
  underneath it.   In reality this  required a fairly  large hunk of
  memory which  I think  was causing  the problem.   This version of
  the monitor  NOW SWAPS  the monitor  out of  memory before running
  LSFIP and then back in when LSFIP is complete.

   This frees  the ENTIRE  memory heap  for LSFIP  to run  in and if
  that was the problem this should  fix it.  Those of you  using EMS
  to swap will find the  running of LSFIP almost instantaneous  now.
  If you are using disk swapping the speed should be about the  same
  but more memory will be available for LSFIP.


  * BYE COMMAND ENHANCEMENTS *

    The  BYE  command  has  been  reworked  so  that in the cases of
  Wildcat!  3.x,  GAP 5.x and  6.x the DROPPED  CARRIER MESSAGE will
  _NOT_ be  written to  the callers  log as  they were  in the past,
  instead they will show as normal logoffs from inside a door.

    For GAP users and door  authors this is significant in  that the
  monitor NOW instructs  GAP to REREAD  door.sys on return  from the
  monitor where  it did  NOT do  this before.   As an  author of GAP
  doors any changes  you wish carried  BACK TO GAP  must be made  to
  DOOR.ORG while the monitor is running.  This file is renamed  back
  to DOOR.SYS  when the  MONITOR exits  and GAP  will reread  it and
  react to changes in any fields that you were manipulating.

    Users of Wildcat! 3.x, the USERINFO.DAT is modified to  indicate
  to WC that the user logged of from outside the system and WC  will
  reread  and  react  to  any  changes  you  as  an  author  make to
  USERINFO.DAT.

    It  should  be  noted  that  the  monitor does NOT manipulate or
  rename or  otherwise tamper  with the  USERINFO.DAT except  in the
  case of  use of  the BYE  command.   All it  does is  read it  in,
  change field 15 to  Y and then write  it back out so  WC knows the
  user logged off normally.


  * LIMITED WWIV DOOR SUPPORT *

    This is  the first  version of  the monitor  to support the WWIV
  format for running doors.

    Due to the  nature of MOST  WWIV doors however,  this support is
  limited so  if you  intend to  try to  run WWIV  doors, read  this
  carefully.

   The BIGGEST problem with running WWIV doors is that most of  them
  do NOT have built in  COMPORT facilities but instead rely  on WWIV
  itself being present to  provide EXTERNAL comport services  to the
  door!

    A FEW  WWIV doors  we tested  had support  for fossil drivers in
  which case  they should  run fine  using LiveCat  and nothing else
  except the fossil installed.

    If the WWIV does NOT have built in comport support and does  NOT
  support  use  of  a  FOSSIL  for  comport  control then you have a
  problem.   You  MUST  use  SOMETHING  to  provide EXTERNAL COMPORT
  SERVICES to the door, which LiveCat does NOT do!

    We recommend  the use  of a  program by  Marshall Dudley  called
  DOORWAY to provide  these external comport  services.  Doorway  is
  an  excellent  program  and  works  very  well  as a complimentary
  product to LiveCat.

    In beta  testing we  had LIMITED  success using  Doorway to  run
  WWIV doors,  but if  you are  willing to  tinker and  play you can
  probably get them to run this way.

    In  order  to  support  the  use  of Doorway in conjunction with
  LiveCat to  run a  WWIV door,  we create  TWO files  if you mark a
  door as type 'I', for WWIV support.

    We create BOTH  a DOOR.SYS and  a CHAIN.TXT file.   The DOOR.SYS
  file is required for DOORWAY to startup and the CHAIN.TXT file  is
  created for  the WWIV  door itself  to use  when DOORWAY starts it
  up.  You must obtain DOORWAY and read it's documentation to  learn
  how  to  use  it  and  attempt  to  set  it up to run these doors.
  Documenting  the  use  of  Doorway  is  beyond  the  scope of this
  documentation.


  * USING LOCKFIX.EXE (Multi-User only)

    Because of circumstances  beyond our control,  a door may  crash
  while  being  run  in  your  system  forcing  a  reboot.   If this
  situation occurs, LiveCat never gets  a chance to reset the  'Door
  In Use' flag in a multi-user  system.  This will result in  a user
  trying to  enter the  door getting  a message  indicating that the
  door is IN USE ON ANOTHER NODE when in fact it is not.

    Previously, the only  way to clear  this condition was  to start
  LSEDIT  and  edit  the  door  script  involved  to change the DOOR
  LOCKED flag from Y back to N.  This was clumsy and time  consuming
  and could  sometimes be  missed for  days until  a user complained
  about it.

    LOCKFIX.EXE  is  provided  with  V  3.5  so  that you may run it
  one of your normal events to  clear these lock flags.  If  none of
  the doors are  in a locked  condition, LOCKFIX does  nothing.  Any
  flags set  to Y  at the  time it  is run  will be  set to N.  This
  program MUST  be run  with all  other nodes  DOWN, or  at least no
  running LiveCat at the time or a sharing violation will occur.

    There are no parameters to  issue or anything else when  LOCKFIX
  is run.  You MUST  however make  sure that  your event  batch file
  changes  to  a  NODEx  directory  before running LOCKFIX.  LOCKFIX
  reads the MONITOR.CFG file to find the LiveCat database files.



[[ WHATS NEXT ? ]]

  At  this  time  we  have  begun  the  engineering  of Version 4.0.
Version  4.0  will  be  almost  a  complete  re-write  of the system
utilizing  EVERYTHING  we've  learned  over  the last few years with
LiveCat.

  I'm obviously not  going to tip  my hand at  this time about  what
the new features  of 4.0 really  are but suffice  it to say  this! V
4.0 will  knock your  socks off!   If you've  liked LiveCat  so far,
you'll LOVE Version 4.0.

  4.0  utilizes  state-of-the-art  in  programming  techniques   and
compiler   technology.    We   are   building   features   into  4.0
that will surprise EVERYONE!  Maybe even US!

  Version 4.0 is due  to be released in  the 3rd quarter of  1992 so
be watching for it, and SEVERAL other significant new products  from
Live Systems this Spring, Summer and Fall.